---
title: Îlots de serveur
description: Combinez du HTML statique très performant avec du contenu dynamique rendu par le serveur.
i18nReady: true
---

Les îlots de serveurs vous permettent de rendre à la demande des « îlos » dynamiques ou personnalisés individuellement, sans sacrifier les performances du reste de la page.

Cela signifie que votre visiteur verra les parties les plus importantes de votre page plus tôt, et permet à votre contenu principal d'être mis en cache de manière plus intensive, ce qui permet d'obtenir des performances plus rapides.

## Les composants d'îlot de serveur

Un îlot de serveur est un [composant Astro](/fr/basics/astro-components/) normal rendu par le serveur, qui est chargé de différer le rendu jusqu'à ce que son contenu soit disponible.

Votre page sera immédiatement affichée avec le [contenu de repli](#contenu-de-repli-de-l%C3%AElot-de-serveur) spécifié en tant que contenu substituable. Ensuite, le contenu du composant est récupéré sur le client et affiché lorsqu'il est disponible.

Avec [un adaptateur installé](/fr/guides/on-demand-rendering/#adaptateurs-de-serveur) pour effectuer le rendu différé, ajoutez la directive [`server:defer`](/fr/reference/directives-reference/#directives-serveur) à n'importe quel composant de votre page pour le transformer en son propre îlot :

```astro title="src/pages/index.astro" "server:defer"
---
import Avatar from '../components/Avatar.astro';
---
<Avatar server:defer />
```

Ces composants peuvent faire [tout ce que vous feriez normalement dans une page rendue à la demande](/fr/guides/on-demand-rendering/#fonctionnalités-de-rendu-à-la-demande) à l'aide d'un adaptateur, comme récupérer du contenu et accéder aux cookies :

```astro title="src/components/Avatar.astro"
---
import { getUserAvatar } from '../sessions';
const userSession = Astro.cookies.get('session');
const avatarURL = await getUserAvatar(userSession);
---
<img alt="Avatar de l'utilisateur" src={avatarURL} />
```

### Transmission de props aux îlots de serveur

Les props fournies aux composants d'îlot de serveur doivent être [sérialisables](https://developer.mozilla.org/fr/docs/Glossary/Serialization) : capables d'être traduites dans un format adapté au transfert sur un réseau ou au stockage. De plus, Astro ne sérialise pas tous les types de structures de données sérialisables. Par conséquent, il existe certaines limitations concernant les propriétés qui peuvent être transmises aux îlots de serveur.

Notamment, les fonctions ne peuvent pas être transmises aux composants marqués avec `server:defer` car elles ne peuvent pas être sérialisées. Les objets avec des références circulaires ne sont pas non plus sérialisables.

Les types de propriétés suivants sont pris en charge :
objet simple, `number`, `string`, `Array`, `Map`, `Set`, `RegExp`, `Date`, `BigInt`, `URL`, `Uint8Array`, `Uint16Array`, `Uint32Array` et `Infinity`

## Contenu de repli de l'îlot de serveur

Lorsque vous utilisez l'attribut `server:defer` sur un composant pour retarder son rendu, vous pouvez « insérer » un contenu de chargement par défaut en utilisant le slot nommé `"fallback"` inclus.

Votre contenu de repli sera rendu avec le reste de la page initialement au chargement de la page et sera remplacé par le contenu de votre composant lorsqu'il sera disponible.

Pour ajouter un contenu de repli, ajoutez `slot="fallback"` sur un enfant (d'autres composants ou éléments HTML) transmis à votre composant d'îlot de serveur :

```astro
---
import Avatar from '../components/Avatar.astro';
import GenericAvatar from '../components/GenericAvatar.astro';
---
<Avatar server:defer>
  <GenericAvatar slot="fallback" />
</Avatar>
```

Par exemple, ce contenu de repli peut être :

- Un avatar générique au lieu de celui de l'utilisateur.
- Une interface utilisateur remplaçable, telle que des messages personnalisés.
- Des indicateurs de chargement tels que des spinners.


## Comment ça marche

L'implémentation des îlots de serveur se fait principalement au moment de la compilation, où le contenu des composants est remplacé par un petit script.

Chacun des îlots marqués avec `server:defer` est divisé en sa propre route spéciale que le script récupère au moment de l'exécution. Quand Astro compile votre site, il omet le composant et injecte un script à sa place, ainsi que tout contenu que vous avez marqué avec `slot="fallback"`.

Lorsque la page se charge dans le navigateur, ces composants sont demandés à un point de terminaison spécial qui effectue leur rendu et renvoie le code HTML. Cela signifie que les utilisateurs verront instantanément les parties les plus importantes de la page. Le contenu de repli sera visible pendant un court laps de temps avant que les îlots dynamiques ne soient chargés.

Chaque îlot est chargé indépendamment des autres. Cela signifie qu'un îlot plus lent ne retardera pas la disponibilité du reste de votre contenu personnalisé.

Ce modèle de rendu a été conçu pour être portable. Il ne dépend d'aucune infrastructure de serveur et fonctionnera donc avec n'importe quel hôte, qu'il s'agisse d'un serveur Node.js dans un conteneur Docker ou du fournisseur sans serveur de votre choix.

## Mise en cache

Les données pour les îlots de serveurs sont récupérées via une requête `GET`, en passant les props sous forme de chaîne chiffrée dans la requête URL. Cela permet de mettre en cache les données avec l'en-tête HTTP [`Cache-Control`](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control) en utilisant des directives `Cache-Control` standard.

Cependant, [le navigateur limite les URL à une longueur maximale de 2048 octets](https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md#url-length) pour des raisons pratiques et pour éviter de causer des problèmes de déni de service. Si votre chaîne de requête fait dépasser cette limite à votre URL, Astro enverra plutôt une requête `POST` qui contient toutes les props dans le corps.

Les requêtes `POST` ne sont pas mises en cache par les navigateurs, car elles sont utilisées pour soumettre des données, et pourraient causer des problèmes d'intégrité ou de sécurité des données. Par conséquent, toute logique de mise en cache existante dans votre projet sera cassée. Dans la mesure du possible, ne transmettez que les props nécessaires à vos îlots de serveurs et évitez d'envoyer des objets de données et des tableaux entiers pour garder votre requête petite.

## Accéder à l'URL de la page dans un îlot de serveur

Dans la plupart des cas, votre composant d'îlot de serveur peut obtenir des informations sur la page qui le rend en [passant des props](/fr/basics/astro-components/#props-de-composant) comme dans les composants normaux.

Cependant, les îlots de serveur fonctionnent dans leur propre contexte isolé en dehors de la requête de la page. `Astro.url` et `Astro.request.url` dans un composant d'îlot de serveur renvoient tous deux une URL qui ressemble à `/_server-islands/Avatar` au lieu de l'URL de la page courante dans le navigateur. De plus, si vous effectuez un pré-rendu de la page, vous n'aurez pas accès à des informations telles que les paramètres de la requête à passer en tant que props.

Pour accéder aux informations de l'URL de la page, vous pouvez vérifier l'en-tête [Referer](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Referer), qui contiendra l'adresse de la page qui charge l'îlot dans le navigateur :

```astro
---
const referer = Astro.request.headers.get('Referer');
const url = new URL(referer);
const productId = url.searchParams.get('product');
---
```

## Réutilisation de la clé de chiffrement

Astro utilise la [cryptographie](https://developer.mozilla.org/fr/docs/Glossary/Cryptography) pour chiffrer les propriétés transmises aux îlots de serveur, protégeant ainsi les données sensibles contre toute exposition accidentelle. Ce chiffrement repose sur une nouvelle clé aléatoire générée à chaque compilation et intégrée dans le regroupement du serveur.

La plupart des hébergeurs de déploiement gèrent automatiquement la synchronisation de votre front-end et de votre back-end. Cependant, une clé de chiffrement constante peut être nécessaire si vous utilisez des déploiements progressifs, un hébergement multirégional ou un CDN mettant en cache les pages contenant des îlots de serveur.

Dans les environnements avec des déploiements continus (par exemple, Kubernetes) où vos ressources front-end (qui chiffrent les props) et vos fonctions back-end (qui déchiffrent les props) peuvent utiliser temporairement des clés différentes, ou lorsqu'un CDN continue de diffuser des pages créées avec une ancienne clé, les props chiffrées transmises à votre îlot de serveur ne peuvent pas être déchiffrées.

Dans ces situations, utilisez la CLI d'Astro pour générer une clé de chiffrement encodée et réutilisable à définir comme variable d'environnement dans votre environnement de compilation :

```shell
astro create-key
```

Utilisez cette valeur pour configurer la variable d'environnement `ASTRO_KEY` (par exemple, dans un fichier `.env`) et l'inclure dans les paramètres de compilation de votre CI/CD ou de votre hôte. Cela garantit que la même clé est toujours réutilisée dans le regroupement généré, garantissant ainsi la synchronisation du chiffrement et du déchiffrement.
